home *** CD-ROM | disk | FTP | other *** search
/ Internet Info 1997 December / Internet_Info_CD-ROM_Walnut_Creek_December_1997.iso / ietf / urn / urn-archives / urn-ietf.archive.9610 / 000102_owner-urn-ietf _Thu Oct 24 15:48:38 1996.msg < prev    next >
Internet Message Format  |  1997-02-19  |  3KB
  1. Received: (from daemon@localhost) by services.bunyip.com (8.6.10/8.6.9) id PAA18285 for urn-ietf-out; Thu, 24 Oct 1996 15:48:38 -0400
  2. Received: from mocha.bunyip.com (mocha.Bunyip.Com [192.197.208.1]) by services.bunyip.com (8.6.10/8.6.9) with SMTP id PAA18280 for <urn-ietf@services.bunyip.com>; Thu, 24 Oct 1996 15:48:36 -0400
  3. Received: from josef.ifi.unizh.ch by mocha.bunyip.com with SMTP (5.65a/IDA-1.4.2b/CC-Guru-2b)
  4.         id AA29165  (mail destined for urn-ietf@services.bunyip.com); Thu, 24 Oct 96 15:48:02 -0400
  5. Received: from ifi.unizh.ch by josef.ifi.unizh.ch 
  6.           id <01466-0@josef.ifi.unizh.ch>; Thu, 24 Oct 1996 21:47:42 +0100
  7. Subject: Re: [URN] Unicode for NSS query
  8. To: gjw@wnetc.com (Gregory J. Woodhouse)
  9. Date: Thu, 24 Oct 1996 21:47:41 +0100 (MET)
  10. Cc: tallen@fsc.fujitsu.com, rdaniel@acl.lanl.gov, urn-ietf@bunyip.com
  11. In-Reply-To: <Pine.SGI.3.95.961024122748.18743D-100000@shellx.best.com> from "Gregory J. Woodhouse" at Oct 24, 96 12:31:49 pm
  12. Mime-Version: 1.0
  13. Content-Type: text/plain; charset=US-ASCII
  14. Content-Transfer-Encoding: 7bit
  15. Content-Length: 2030
  16. From: Martin J Duerst <mduerst@ifi.unizh.ch>
  17. Message-Id: <"josef.ifi..582:24.09.96.20.47.43"@ifi.unizh.ch>
  18. Sender: owner-urn-ietf@services.bunyip.com
  19. Precedence: bulk
  20. Reply-To: Martin J Duerst <mduerst@ifi.unizh.ch>
  21. Errors-To: owner-urn-ietf@bunyip.com
  22.  
  23. >
  24. >On Thu, 24 Oct 1996, Martin J Duerst wrote:
  25. >
  26. >> 
  27. >> I have suggested that we might be required to thing in terms of
  28. >> both characters and octets. For some things, similar to a data:
  29. >> URL, thinking in characters might be artificial. For some
  30. >> other things, such as URLs, thinking in octets may to some
  31. >> extent be necessary because of backwards compatibility issues
  32. >> (assume an URL scheme is extended and decides to use some
  33. >> weird RFC 1522-like method for encoding characters, and this
  34. >> would have to be grandfathered).
  35. >>
  36. >
  37. >I have thought about the same thing, and I admit that I am not altogether
  38. >enthusiastic about RFC 1522 style encoding of URNs, but it may be forced
  39. >upon us. 
  40.  
  41. Well, I didn't mean that this is currently the case. The ftp
  42. i18n extensions, for example, are happily going in the direction
  43. of UTF-8 and would very well fit together with our proposal.
  44.  
  45. But I have made the experience that trying to specify UNicode only
  46. can meet quite some resistance. Some people, for whatever reasons,
  47. are strongly anti-unicode. If you specify something like
  48. "urns use Unicode and nothing else", they may start to complain.
  49. If you say "urns should use Unicode, and clients should interpret
  50. urns as Unicode if possible, but if really necessary, an NSS
  51. can use something else" then it's difficult to oppose, even
  52. if maybe in actual practice, there will not be a single NSS
  53. that ever specifies something else than Unicode.
  54.  
  55. NSSs or URL shemes (I still have problems distingushing them)
  56. themselves might also do the same thing, namely saying that
  57. in general, character semantics should be ISO 10646/UTF-8, but
  58. that other things would be tolerated for backwards compatibility.
  59. This is exactly the case for ftp, where a lot of 8-bit filenames
  60. are already existing and in use, although not UTF-8.
  61.  
  62. It is also important because not every arbitrary sequence of
  63. 8-bit octets is an UTF-8 sequence. What should browsers, resolvers,
  64. and all the other components of our URN arichitecture do with
  65. these?
  66.  
  67.  
  68. Regards,    Martin.